home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Aug 90 / MacApp.Tech$ 8⁄10⁄90 / 1724-Re MemoryMgrProblem-Aug90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.3 KB  |  62 lines  |  [TEXT/GEOL]
  1. Item    4737032                         9-Aug-90        09:46PDT
  2.  
  3. From:   KNEPPER                         Knepper, Christopher
  4.  
  5. To:     AUST0334                        AUDev - CRIA, Canberra, ACT,IDV
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Re: MemoryMgrProblem
  10.  
  11. Martin,
  12.  
  13. >Recently I have been experiencing a few run-time bugs with our MacApp
  14. >application.  Various pictures were being deleted when memory was tight etc.
  15.  
  16. I'd like to offer a different explanation to the one that you came up with
  17. involving MacApp's memory management. What I think is happening is this. The
  18. TPicture object loads a purgeable 'PICT' resource. This resource fits in the
  19. application heap just fine when heap space isn't tight, but it gets purged when
  20. heap space gets tight. This is actually a feature of the Macintosh Memory
  21. Manager and has nothing to do with MacApp's permanent/temporary memory.
  22.  
  23. When you run your application in tight memory situations, the 'PICT' resource
  24. gets purged because the memory manager needs the space and notices that the
  25. 'PICT' resource is a purgeable block. After the Macintosh Memory Manager purges
  26. the block, the master pointer contains a NIL entry. When your application
  27. attempts to image the TPicture object, the TPicture.Draw method _tries_ to load
  28. the 'PICT' resource with a LoadResource call. If there isn't enough memory in
  29. the application heap space, the LoadResource call fails and TPicture.Draw
  30. (correctly) does nothing. Here's the code from MacApp 2.0:
  31.  
  32. PROCEDURE TPicture.Draw(area: Rect); OVERRIDE;
  33.  
  34.    VAR
  35.    oldState:   SignedByte;
  36.    theRect:Rect;
  37.  
  38.    BEGIN
  39.    IF fDataHandle <> NIL THEN
  40.    BEGIN
  41.    IF fRsrcID <> kNoResource THEN
  42.    LoadResource(Handle(fDataHandle));
  43.    IF fDataHandle^ <> NIL THEN { If there's room for the picture… }
  44.    BEGIN
  45.    ...draws the picture...
  46.    END;
  47.    END;
  48.    INHERITED Draw(area);
  49.    END;
  50.  
  51. So, what I suggest that you do is either:
  52.  
  53. 1. make your 'PICT' resources smaller, or
  54. 2. increase your temporary reserve by adding a 'mem!' resource to your
  55. application.r file as described in the MacApp 2.0 General Reference (chapter
  56. 3). This increase the space used for noncode temporary requests. You may have
  57. to determine empirically how much space to add to the temporary reserve,
  58. although 2K should do (depending on the size of your largest picture).
  59.  
  60. -Chris
  61.  
  62.